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(54) System and method for storing firmware in a human-implantable medical treatment device 



(57) In a medical treatment device implanted within 
the body of a patient, a system and method for organiz- 
ing storage of the device's firmware in ROM, RAM, and 
EEPROM such that a ROM-based system is imple- 
mented initially using pointers stored in RAM, which 
RAM-based pointers point to ROM-based functions. 
When revisions to the functionality of the treatment 
device are desired, code is downlinked via an external 
programmer and telemetry to link to RAM, and one or 
more pointers, as appropriate, which pointers point to 



the downlinked code in RAM, are downlinked to RAM. In 
this manner, revisions to the firmware of an implanted 
medical treatment device can be downlinked to the 
device thereby eliminating the need to explant the 
device in certain circumstances. The amount of code 
placed in ROM is maximized, with only pointers to func- 
tions and new or revised code segments stored in RAM 
as needed. 



in* 



-f- 



,20t 




POMB? . 



-3tt 



Q. 
LU 



Printed by Xerox (UK) Business Services 
2.16J (HRS)/3£ 



1 



EP 1 048 323 A2 



2 



Description 

[0001] This invention relates to storing firmware in a 
medical treatment device, such as a drug infusion pump 
or an electrical nerve stimulator, that is implanted within s 
a patients body and downloading revisions and/or. addi- 
tions to the firmware without explanting the treatment 
device. 

[0002] Devices and techniques for treating neuro- 
logical disorders by drug infusion and by electrical stim- 10 
ulation of a person's central nervous system are well 
known in the prior art. For instance, U.S. Patents 
5,713,922 to King, 5,782,798 to Rise, and 5,814,014 to 
Elsberry et al., each assigned to Medtronic, Inc. of Min- 
neapolis, Minnesota, disclose such devices and tech- 75 
niques. 

[0003] Such treatment devices and techniques 
often employ drug-infusion pumps and/or electrical 
pulse generators that are implanted within a patient's 
body. Accordingly, available memory for storing control 20 
software and operating parameters, also referred to as - 
firmware, such as treatment dose, duration, and timing, 
of various treatment protocols is severely limited relative 
to the amount of memory typically available to systems 
that are not implanted within a person's body 25 
[0004] The use random access memory ("RAM") 
. and read only memory ("ROM") each have their advan- 
tages and disadvantages in the context of implantable 
medical treatment devices. With respect to accessing 
memory, ROM uses less energy and is therefore prefer- 30 
able to RAM for storing the firmware of an implantable 
medical treatment device because it increases the use- 
ful life of the device, thereby reducing the need for 
explanting a device due to a discharged battery. ROM, 
however, is less flexible to the extent that RAM can be 35 
modified, whereas ROM can not be modified without 
explanting the device. The flexibility provided by the 
capability to modify RAM also raises concerns about 
RAM-based code becoming unintentionally corrupted. 
ROM storage devices offer another advantage, namely, 40 
ROM devices typically require less area on an inte- 
grated circuit chip thereby advantageously reducing the 
size of the treatment device. 

[0005] Making modifications to the software for con- 
trolling such treatment devices without explanting the 45 
devices is often desirable. For instance, modifications to 
the control software are desirable as new treatment 
modes are developed. 

[0006] Optimization techniques for efficiently using 
the limited amount of available memory provided by an 50 
implantable treatment device have been addressed by 
certain prior art patents. For instance, U.S. Patent 
5,360,437 to Thompson discloses an implantable medi- 
cal device having its control program or software stored 
in non-volatile random access memory ("RAM"). The 55 
non-volatlie RAM can be re-programmed as desired 
using an external programmer and a telemetry link. U.S. 
Patent 5,456,691 to Snell discloses a system in which 



only certain physician-selected program modules are 
loaded into the implantable devices RAM. RAM require- 
ments can be reduced by loading only a limited number 
of program modules into RAM. These approaches 
undesirably fail to take advantage of the benefits pro- 
vided by maximizing the use of ROM. 
[0007] U.S. Patent 5,456,692 to Smith, Jr. et al. dis- 
closes an implantable pacemaker in which the control 
program is stored in read only memory ("ROM") or an 
equivalent non-volatile memory storage device. Control 
parameters, on the other hand, are stored in RAM, and 
may be programmably altered in order to allow the 
pacemaker to meet the potentially changing needs of a 
patient. A drawback to this approach, however, is that it 
is difficult to predict all of the parameters that may need 
to be modified in the future. For instance, the motor of 
an implantable drug-infusion pump is typically powered 
by a battery that outputs electrical pulses of varying 
characteristics as the battery voltage decreases. For 
instance, a fully charged battery could drive the pulses 
at a 10% duty cycle, while a substantially discharged 
battery's duty cycle could expand to close to 100%. If 
the developers of the control software for a drug infusion 
pump were unaware that changing the battery duty 
cycle characteristics would be desirable or necessary in 
the future, the related parameters would not be placed 
in RAM. If those parameters were placed in ROM, they 
could not be changed without explanting the pump. 
[0008] Accordingly, in light of the significant mem- 
ory power and size limitations and the safety concerns 
associated with storing control or operating software in 
an implantable medical device, there remains a need for 
an improved system and method providing a flexible 
arrangement that takes advantages of the benefits pro- 
vided by the use of both ROM and RAM in the context of 
an implantable medical treatment device. 
[0009] In a first aspect of this invention, there is pro- 
vided a system for storing control software in a human- 
implantable medical treatment device, the system com- 
prising: 

a read only memory (•ROM'') for storing the code of 
a plurality of tasks to be performed by the medical 
treatment device; 

a random access memory ("RAM') for storing point- 
ers to the tasks; 

a programmer and telemetry link for downlinking to 
the RAM code and pointers to the downlinked code 
so that the medical treatment device executes both 
the ROM-based tasks and the RAM-based down- 
linked tasks. 

[0010] The firmware, also referred to as control 
software, is stored in such a manner that the amount of 
code stored in ROM is maximized and RAM storage is 
used for staring pointers to functions, the relative priority 
and/or execution order of functions, and any code down- 
linked via the external programmer and telemetry link. 
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When code is downlinked to and stored in RAM, one or 
more revised and/or new pointers to the code that has 
been downlinked to RAM are also downlinked and 
stored in RAM. In this manner, execution of ROM-based 
tasks can be terminated by downlinking a pointer to exe- 5 
cute a downlinked task in RAM, instead of executing a 
ROM-based task. 

[0011] In another aspect of the present invention, 
there is provided A hybrid random access memory 
("RAM") and read only memory ("ROM") system for use w 
in a medical treatment device that is implantable within 
the body of a patient, the system comprising: 



a ROM containing 



15 



a function defaults module for storing functions 
in the ROM, 

a function pointer defaults module for storing 
pointers to the functions stored in the function 
defaults module of the ROM, 20 
an executive/task scheduler for executing func- 
tions pointed to by stored function pointers, and 
a task order defaults module for defining the ini- 
tial order in which ROM-based tasks are exe- 
cuted; 25 

a RAM containing 

a function pointer table for storing pointers to 
the functions executed by the executive/task 30 
scheduler, the function pointer table being ini- 
tialized by copying the contents of the function 
pointer defaults module from the ROM and, 
a downlinked functions module for storing 
downlinked functions, and 35 
a task order table for storing downlinked defini- 
tions of the order in which ROM-based tasks or 
- RAM-based tasks, or both ROM-based tasks 
and RAM-based tasks are executed, the task 
order table being initialized by copying the con- aq 
tents of the task order defaults module of the 
ROM; and 

a programmer and telemetry link for downlinking 
the functions stored in the downlinked functions as 
module of the RAM. 



module for storing functions in the ROM, a function 
pointer defaults module for storing pointers to the func- 
tions stored in the function defaults module of the ROM, 
an executive/task scheduler for executing functions 
pointed to by stored function pointers, and a task order 
defaults module for defining the initial order in which 
ROM-based tasks are executed based, at least in part, 
upon the order in which pointers to tasks are stored in 
the task order defaults module. 
[0014] The RAM may contain a function pointer 
table initialized by copying the contents of the function 
pointer defaults module from the ROM and for storing 
pointers to the functions executed by the executive/task 
scheduler, a downlinked functions module for storing 
downlinked functions in addition to the functions stored 
in the function defaults module of the ROM, and a task 
order table initialized by copying the contents of the task 
order defaults module of the ROM and for storing down- 
linked definitions of the order in which ROM-based 
tasks or RAM-based tasks, or both ROM-based tasks 
and RAM-based tasks, are executed. 
[0015] The EEPROM may contain a function 
pointer changes module for storing a back-up copy of 
the contents of the function table pointer of the RAM, a 
function changes module for storing a back-up copy of 
the downlinked functions module of the RAM, and a 
task order changes module for storing a back-up copy of 
the task order table of the RAM. 
[0016] In yet another aspect of this invention, there 
is provided a method of storing control software in a 
human-implantable medical treatment device compris- 
ing the steps of: 

storing a task scheduler and the code of a plurality 
of tasks to be performed by the medical treatment 
device in a read only memory ("ROM"); 
storing pointers to the tasks in a random access 
memory ("RAM"); and 

downlinking to the RAM code and pointers to the 
downlinked code such that the medical treatment 
device executes both the ROM-based tasks and the 
RAM-based downlinked tasks. 
Steps for implementing a tiered fault recovery strat- 
egy analogous to the one set forth above with 
respect to the first embodiment may also be 
included. 



[0012] The downlinked code and pointers may be 
stored in an electrically erasable programmable read 
only memory ("EEPROM") before the downlinked code so 
and pointers are stored in the RAM. Upon detecting a 
RAM fault, the RAM-based downlinked code and point- 
ers may be restored from the contents of the EEPROM. 
Upon failure of the restoration of RAM from EEPROM, 
execution of one or more RAM -based functions may be ss 
terminated, and execution of one or more ROM-based 
tasks can be reinstated. 

[0013] The ROM may contain a function defaults 



[0017] Preferred embodiments will now be 
described, by way of example only, with reference to the 
drawings. 

FIG. 1 is a schematic view of a patient with a treat- 
ment device implanted within the patienfs body. 
FIG. 2 is a data flow diagram showing the Mow of 
data between portions of different types of memory 
storage devices in accordance with the principles of 
this invention. 

FIG. 3 is a simplified flow chart depicting steps for 
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storing the firmware of an implantable medical 
treatment device in accordance with the principles 
of this invention. 

FIG. 4 is a simplified flow chart depicting steps for 
implementing a tiered fault recovery strategy in 
accordance with the principles of this invention. 

[0018] FIG. 1 is a schematic view of a patient 10 
having treatment device 14 implanted within the 
patient's body. Implantable treatment device 14 is pro- 
grammable through a telemetry link from programmer 
20, which is coupled via a conductor 22 to a radio fre- 
quency antenna 24. 

[0019] FIG. 2 is a data flow diagram showing the 
flow of data between portions of different types of mem- 
ory storage devices within treatment device 14 in 
accordance with the principles of this invention. Upon 
initialization of the implanted medical device 14, func- 
tion pointer defaults 200 are copied from read only 
memory ("ROM") 202 into function pointer table 204 in 
random access memory ("RAM") 206, as indicated by 
arrow 208. RAM 206 could be an FRAM as disclosed in 
commonly assigned U.S. Patent 5,360,437 to Thomp- 
son. Of course other suitable storage devices could also 
be used. 

[0020] Also during initialization of device 14, task 
order defaults 21 0 are copied into task order table 21 2, 
as indicated by arrow 214. This task order data speci- 
fies relative priorities among tasks to be executed. Upon 
completion of initialization, executive/task scheduler 
216 executes tasks in the order in which they appear in 
task order table 212. Functions, methods, subroutines, 
and the like, that are part of one or more tasks, are 
called using pointers to functions, which pointers are 
contained in function pointer table 204. 
[0021] Tasks generally refer to higher level routines, 
whereas functions generally refer to lower-level rou- 
tines, as these terms are used in this specification,. 
There is no bright-line distinction, however, between the 
way the terms task and function are used herein. 
Accordingly, the terms should be considered inter- 
changeable for purposes of this specification, including 
the appended claims. The term code as used herein 
includes, but is not limited to, program instructions, var- 
iables, constants, pointers, and the like. 
[0022] Under normal operation, upon completion of 
initialization, function pointer table 204 contains point- 
ers to functions contained in function defaults 21 8 within 
ROM 202. These pointers are symbolically represented 
in FIG. 2 as two-segment arrow 220-1 and 220-2. 
Accordingly, the ROM-based software for implementing 
the original functionality of device 14 is stored in execu- 
tive/task scheduler 216 and function defaults 218 of 
ROM 202. 

[0023] When a modification, addition to, or deletion 
from, the control software of device 14 is desired, soft- 
ware for implementing revised functionality or new func- 
tionality is downlinked from programmer 20 and stored 



in function changes module 222. One or more corre- 
sponding revised function pointers are downlinked from 
programmer 20 to function pointer changes module 
226. The revised function pointers are then copied from 

5 the function pointer changes module 226 of EEPROM 
module 228 to function pointer table 204. The revised 
function pointers point to downlinked functions module 
230 in RAM 206, as depicted by double segment arrow 
220-1 and 220-3. Downlinked functions module 230 

,o then contains a copied version of the contents of func- 
tion changes module 222. 

[0024] Revisions to the priority or order in which 
tasks are executed can be downlinked to task order 
changes module 224 and then copied into task order 

75 table 212. In this manner, new tasks can be added, 
existing tasks can be deleted, and tasks can be priori- 
tized relative to one another. Because every major task 
is called based on a pointer to a function, at any level in 
the. control program, whether ifs at a task level or a 

20 function level, a revised or new task or function can be 
downlinked and replace an existing task or function by 
also changing the corresponding task or function 
pointer to no longer call the original ROM-based func- 
tion and to call the downlinked, revised or new, RAM- 

25 based task or function instead. 

[0025] Although task scheduler 216 is depicted 
separately from other functions, it may be modified by 
downlinking code to RAM 206 to modify the functionality 
of task scheduler 216 in an analogous manner as set 

30 forth for other functions. 

[0026] While no foreground tasks are executing, 
CRC checks are typically run in the background on 
ROM 202, RAM 206, and EEPROM 228. By having 
back-up copies of the RAM-based downlinked functions 

35 module 230 and task order table 212 in function 
changes 222 and task order changes 224 in EEPROM 
228, if any errors are detected in either downlinked func- 
tions module 230 or task order table 212, the errors can 
be corrected by copying the corresponding back-up ver- 

40 sion of the data from E EP RO M 228. 

[0027] If a latent failure occurs in a particular area of 
ROM or RAM, any tasks and/or functions located in the 
affected area of ROM or RAM may become inoperable. 
In accordance with the principles of this invention, 

45 firmware may be downlinked to RAM, along with one or 
. more corresponding revised function pointers, so that 
replacement functions for the inoperable tasks and/or 
functions can be operated out of RAM, instead of ROM. 
As a result, the need to explant the implanted medical 

so device as a result of certain latent memory failures can 
be avoided. Details of a tiered fault recovery strategy for 
recovering from a RAM fault are set forth below in the 
discussion of FIG. 4. 

[0028] FIG. 3 is a simplified flow chart depicting 
55 steps for executing tasks and/or functions out of ROM 
202 and/or RAM 206, as desired, in accordance with the - 
principles of this invention. Initially, as depicted at 300, 
function pointer defaults and task order defaults are 
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copied from ROM 202 to RAM 206. Whether a change 
in the functionality of the implanted medical treatment 
device is desired is checked as depicted at 302. If such 
a change in functionality is desired, revised task, func- 
tion, and/or task priorities are downlinked to RAM 206, 5 
as depicted at 304. Then, as depicted at 306, pointers 
are downlinked to RAM 206, which pointers point to the 
revised one or more tasks and/or functions downlinked 
to RAM 206 in step 304. Then, existing ROM-based 
tasks and functions for which no modification has been w 
downlinked in steps 304 and 306 are executed from 
ROM in the normal fashion and any downlinked tasks or 
functions are executed from RAM, as depicted at 308. 
Processing then returns to step 302 to check whether 
additional functionality changes are desired. If so, steps 15 
304 and 306 are repeated. If no additional functionality 
changes are desired, steps 304 and 306 are bypassed 
and processing proceeds to step 308. 
[0029] Referring to FIG. 4, downlinked code and 
pointers are stored in EEPROM 228 before they are 20 
stored in RAM 206, as depicted at 400. If a RAM fault is 
detected, the RAM-based downlinked code and point- 
ers are restored from EEPROM, as depicted at 402 and 
404; If restoring the downlinked code and pointers from 
EEPROM does not cure the RAM fault, execution of any 25 
RAM-based tasks affected by the RAM fault is termi- 
nated, as depicted at 406 and 408, and execution of any 
ROM-based tasks corresponding to respective termi- 
nated RAM-based tasks is reinstated as depicted at 
410. 30 

Claims 

1. A system for storing control software in a human- 
implantable medical treatment device, the system 35 
comprising: 

a read only memory ("ROM") (202) for storing 
the code of a plurality of tasks to be performed ' 
by the medical treatment device; & 
a random access memory ("RAM") (206) for 
storing pointers to the tasks; 
a programmer (20) and telemetry link for down- 
linking to the RAM code and pointers to the 
downlinked code so that the medical treatment 45 
device executes both the ROM-based tasks 
and the RAM-based downlinked tasks. 

2. The system as in claim 1 further comprising means 

for storing the downlinked code and pointers in an so 
electrically erasable programmable read only mem- 
ory ("EEPROM') (228) before the downlinked code 
and pointers are stored in the RAM. 

3. The system as in claim 2 further comprising means 55 
for restoring the downlinked code and pointers to 
RAM from the EEPROM upon detecting a RAM 
fault 
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4. The system as in claim 3 further comprising means 
for terminating execution of at least one RAM- 
based task upon failure of the means for restoring 
the downlinked code and pointers from EEPROM to 
cure the RAM failure. 

5. The system as in claim 4 further comprising means 
for reverting back to execution of at least one ROM- 
based task corresponding to the at least one RAM- 
based task for which execution was terminated. 

6. A hybrid random access memory ("RAM") and read 
only memory ("ROM") system for use in a medical 
treatment device that is implantable within the body 
of a patient, the system comprising: 

a ROM (202) containing 

a function defaults module (21 8) for storing 
functions in the ROM, 
a function pointer defaults module (200) for 
storing pointers to the functions stored in 
the function defaults module of the ROM, . 
an executive/task scheduler (216) for exe- 
cuting functions pointed to by stored func- 
tion pointers, and 

a task order defaults module (210) for 
defining the initial order in which ROM- 
based tasks are executed; 

a RAM (206) containing 

a function pointer table (204) for storing 
pointers to the functions executed by the 
executiveAask scheduler, the function 
pointer table being initialized by copying 
the contents of the function pointer 
defaults module from the ROM and, 
a downlinked functions module (230) for 
storing downlinked functions, and 
a task order table (212) for storing down- 
linked definitions of the order in which 
ROM-based tasks or RAM-based tasks, or 
both ROM-based tasks and RAM-based 
tasks are executed, the task order table 
being initialized by copying the contents of 
the task order defaults module of the ROM; 
and 

a programmer (20) and telemetry link for down- 
linking the functions stored in the downlinked 
functions module of the RAM. 

7. The system as in claim 6, further comprising: an 
electrically erasable programmable read only mem- 
ory (228) containing: 

a function pointer changes module (226) for 
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storing a back-up copy of the contents of the 
function table pointer of the RAM, 
a function changes module (222) for storing a 
back-up copy of the downlinked functions mod- 
ule of the RAM, and 

a task order changes module (224) for storing a 
back-up copy of the task order table of the 
RAM. 



15. The method as in claim 14 further comprising the 
step of reverting back to execution of at least one 
ROM-based task corresponding to the at least one 
RAM-based task for which execution was termi- 
5 nated. 



8. The system as in claim 7 further comprising means 10 
for restoring the contents of at least one module of 
the RAM, upon a RAM failure, by copying the con- 
tents of the corresponding back-up module from the 
EEPROM. 

15 

9. The system as in claim 8, further comprising means 
for terminating execution of at least one RAM- 
based function upon failure of copying the contents 
of the corresponding back-up module from EEP- 
ROM to cure the RAM failure. 20 

1 0. The system as in claim 9, further comprising means 
for executing at least one ROM-based function cor- 
responding to the at least one terminated RAM- 
based function. 25 



11. A method of storing control software in a human- 
implantable medical treatment device comprising 
the steps of: 

30 

storing a task scheduler and the code of a plu- 
rality of tasks to be performed by the medical 
treatment device in a read only memory 
("ROM") (202); 

storing pointers to the tasks in a random 35 
access memory ("RAM") (206); and 
downlinking to the RAM code and pointers to 
the downlinked code such that the medical 
treatment device executes both the ROM- 
based tasks and the RAM-based downlinked 40 
tasks. 

12. The method as in claim 1 1 further comprising the 
step of storing the downlinked code and pointers in 

an electrically erasable programmable read only 45 
memory ("EEPROM") (228) before the downlinked 
code and pointers are stored in the RAM. 



13. The method as in claim 12 further comprising the 
step of restoring the downlinked code and pointers so 
to RAM from the EEPROM upon detecting a RAM 
fault. 

14. The system as in claim 13 further comprising the 
step of terminating execution of at least one RAM- 55 
based task upon failure of restoring the downlinked 
code and pointers from EEPROM to cure the RAM 
failure. 
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